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Abstract: In this paper we describe a general method to prove termination of C programs in 

a scalable and modular way. The program to analyse is reduced to the smallest relevant subset 
through a termination-specific slicing technique. Then, the program is divided into pieces of 
code that are analysed separately, thanks to an external engine for termination. The result is 
implemented in the prototype SToP over our previous toolsuite WTC ([2]) and preliminary results 
shows the feasibility of the method. 
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Terminaison Modulaire pour programmes C 

Resume : Dans ce rapport nous decrivons une methode generale, modulaire et passant a 
l’echelle pour prouver la terminaison de programmes C quelconques. Le programme a analyser 
est reduit via une technique de slicing specifique a un programme C contenant uniquement les 
parties pertinentes pour la preuve de terminaison. Ensuite, le programme est decoupe en petits 
bouts de code qui sont analyses separement, grace a un programme externe. Cette methode est 
implementee dans un prototype nomme SToP par dessus notre chaine d’outils existante WTC 
[I] et les resultats preliminaires montrent la pertinence de la methode. 

Mots-cles : Analyse statique, terminaison, modularise, programmes C 
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1 Introduction 

Although proving program termination is known to be undecidable, recent progress in program 
analysis made it possible to predict the termination of an always increasing class of sequential 
programs. The standard approach of the seminal paper [9] which consists in finding a function 
from the states of the program to some well-founded set, which strictly decreases at each program 
point, remains standard. In [2, we proposed a general algorithm to discover multidimensional 
ranking functions from flowcharts programs, by means of the resolution of linear programing (LP) 
instances. However, our experiments showed two main problems to scale to larger C programs : 

• Although our C parser, namely C2fsm (|S]) was designed to handle a large part of C syntax, 
many syntactical variants are not handled. Most of them could be ignored to prove the 
termination. 

• Moreover, the size of the LP problems increases with the number of code lines, and thus 
quickly become intractable. 

In this paper, we propose an effective modular interprocedural termination analysis, which relies 
on the previous method, but enables to analyse a broad range of C programs, and validate this 
approach on a large benchmark of the literature. Our method relies on classical methods from 
static analysis and compilation, such as slicing and summaries, but as far as we know, is the first 
attempt in proving termination of a large set of C programs in a modular way. 

The rest of the paper is organized as follows. In section [2j we introduce our motivation 
of a challenging program of the literature. In section [3] we quickly introduce our notation and 
theoretical foundations. In section [1] w e describe our method, and we evaluate it on a large bench 
of middle-sized programs in section [6| We end with related works (section [?| and a conclusion. 
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2 Motivating example 


In this paper we detail our method on an implementation of the merge sort of an array. The 
code is taken from (5j and is depicted in Figure [l] For sake of lisibility, we drawed boxes around 
innerloops, and commented the end of outer loops. 


1 int main () { 

2 int n,i ,j ,k,l ,t,li, m, p , q , r ; 

3 int up; /* really boolean */ 

4 int a[2*n + l] 

s up = 1; p = 1; 


7 loop4 : do{ 


sorting a 


h = 1; 
m = n; 
if (up = 1 ){ 

i = i; 

j = n; 

k = n + 1; 

1 = 2*n; 

} else { 

k = 1; 

1 


J 


n; 

n+ 1 ; 
2 *n ; 


} 

loop5 


do{ 

i f (m >= p ) 

q = p ; 
else q = m; 
m = m—q ; 
i f (m >= p ) 
r = p ; 
else r = m; 


m 


m—r ; 


loopO : while(q>0 r>0) { 
if(a[i] < a [ j]){ 
a[k] = a[ i ] ; 
k = k+h; 
i = i +1; 
q = q-i; 

} else { 

a[k] = a[j]; 
k = k+h; 
j = j -i; 

r = r — 1;} 


loop 1 

: while(r > 

0 ){ 

a 

[k] = a lj]; 


k 

= k+h; 


j 

= j -i; 


r 

= r — 1 ; 

} 


loop2 : while(q > 0){ 
a [ k] = a [ i ] ; 
k = k+h; 
i = i +1; 
q = q —l; 

— } -—- 

li = —h ; 

t = k; 

k = 1 ; 

1 = t; 

} while(m> 0 )\//end of loop5 

up = 1—up; 

p = 2*p; 

} while (p<n ); //end of loopf 


//final copy of the array in the first half of a 
if (up = 0 ){ 
i = 1 ; 


loop3 : while( i <= n){ 
a[i] = a[i+n]; 

i = i + 1 ; 

4- 


}//end if test up==0 

return 0 ; 


Figure 1: Our motivating example: iterative merge sort 
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Figure 2: WTC toolchain 

Calling our tool suite (Figure |2j detailed in j2] and [8] gives an intermediate automaton of 12 
variables, 80 transitions and 9 locations. Aspic successfully computes the invariants but Rank 
fails with TWO_MUCH_VARIABLES error because the size of the underlying linear programming 
problem is too big. 

The whole computation time is 12 seconds on a Intel Core2 @ 1.60GHz. In the following, 
we will show how our method SToP , finally manages this code to prove its termination. 
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3 Preliminaries 

3.1 Grammar for intraprocedural analysis 

We define in Figure [3] a rather classical “mini while” grammar for programs, named G. 

(prog):— (declaration list) (statement list) 

(declaration list)::=(decl) (declaration list) | (empty) 

(decl)::=bool (ident) | int (ident) 

(statement list)::=(statement) (statement list) | (empty) 

(statement) ::= (assignment) | (ifstat) | (forstat) | (whilestat) 
l(assertstat) | (breakstat) 

(assignment) ::= (var) := (expr) 

(ifstat) ::= if (expr) then (statement list) else (statement list) 

(forstat) ::= for (var) from (expr) to (expr) do (statement list) 

(whilestat) ::= while (formula) do (statementlist) 

(breakstat) ::= break 

(assert stat) ::= assert (formula) 


Figure 3: A simple grammar G for programs 


Expressions are simple Boolean and numerical expressions without side-effects. The semantics 
of the programs is rather classical too and we do not detail it. 

On this kind of programs, the problem of proving termination is undecidable, but like in [2] 
we will provide a sound (but not complete) analysis that is able to deal with a large bench of 
problems. Basically, the method described in this paper is based on the fact that while loops 
can be proven to be terminating quite independently of the other ones, provided that we keep 
an execution context precise enough, thanks to the notion of summary. 

3.2 Summaries 

Definition 3.1 Let C £ G be a statement and Rq(xo, yo, x, y) the relationship between the values 
of the variables before and after C. C' £ G is said to be an abstraction of C if Rc C Re- 

It is obvious that if we manage to prove that C terminates, then C terminates. Thanks to linear 
relation analysis, we are able to compute such abstractions of code behaviours. We again use 
Aspic ([8]) with the appropriate option to obtain a polyhedral over-approximation Rc{x o, yo , x, y) 
of the behaviour of a given code C. 

Definition 3.2 (Summary) Let C be a code and Rc{xq, yo,..., x, y) be an over-approximation 
of the relation between initial variables xo, yo, ■ ■ ■ and final variables x, y, .... Then the following 
code is called a summary of C : 

xO = x; yO = y; ... 

x = randomO ; y = randomO ; . . . 

if(!R_C(xO,yO, ..., x, y, ...)) break 

The summary of C is obviously an abstraction of C and thus can be used for proving the 
termination of C. 
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4 Intraprocedural modular termination 

This section presents a termination procedure able to handle large programs. Our termination 
procedure is based on the following remarks. 

• The program terminates if and only if all the conditional loops (referred as “while loops” in 
the following) terminate. Hence, the termination analysis can focus on the smallest program 
slice which contains the while loops and the minimum subset of instructions to preserve 
their behaviour. This preprocessing is called termination-specific slicing and described in 
subsection |4.1[ In general, the slicing reduces drastically the program size. However, this 
may not be sufficient (see for example our motivating example) and the following analysis 
is generally required. 

• Basically, a while loop terminates if and only if (i) the body terminates for each iteration 
and (ii) the while loop itself terminates. This simple idea allows to decompose a big 
termination problem into several termination sub-problems, small enough to be processed 
successfully by WTC. The detail of the decomposition is presented in subsection |4.2| 

4.1 Step 1. Termination-Specific Slicing 

The termination-specific slicing step is a preprocessing which extracts the program subset relevant 
for proving termination. This subset must contains the while loops and the instructions required 
to preserve their behaviour. 


1 if (up = 0){ 

2 i = 1; 

3 while ( i <= n) { 

4 a [ i ] = a [ i+n ] ; 

5 i = i+1; 

6 } 

7 } 

(a) Before slicing 


1 if (up == 0 ) { 

2 i = 1 ; 

3 while ( i <= n) { 

4 i = (i + i); 

5 } 

6 } 

(b) After slicing 


Figure 4: Example for slicing taken from our motivating example 


Consider the example given in figure [4] Clearly, for each variable used in the while condition, 
the definition sites must be kept (here, i=l and i=i+l). But the variables read by these definitions 
sites must be kept as well, and so on. This process boils down to a backward traversal of the data 
dependencies, starting from the variables used in the while condition. Also, control dependencies 
must be taken into account. On the example, the while loop will be executed only when the 
then branch is chosen. In turn, this depends on the up variable, on which the same process 
must be applied. These are the basic ideas of program slicing, for which many variants has been 
developed [133 f° r various purposes as reverse engineering, program comprehension,... 

Our termination-specific slicing algorithm is depicted in Algorithm [TJ 

• Do_SLiCE(function_body), the main function, selects the set of while statements of the 
current function_body and runs the main slicing function, Slice. Do_ Slice is applied 
to each function body of the program. 

• SLiCE(stmt_set) proceeds the definition sites of stmt_set with a depth-first traversal, 
flooding the connex part of stmt_set in the meaning of Definition_Sites. Notice that 
the function mark(stmt) adds the line of stmt to the slice. When stmt is a control structure 
(if, for,while,...), only the control lines are added (e.g. if, else, {, }), not the body. 
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• DEFINITION_ SITES (stmt) computes the set of statements whose stmt depends immediately, 
in the meaning of data- and control-dependence. More precisely, Definition_Sites com¬ 
putes the reaching definitions |T| RD s t m t(xi) of each variable xi read by stmt. The result 
is a set of assignments which can possibly define the value of xi read by stmt. Also, the 
immediate compound control structure of stmt, COMPOUND(stmt), is added if it exists. 
This way control dependencies are taken into account. 


Algorithm 1 Termination-Specific Slicing Algorithm 

i: function Do_SLIcE(function_bodv) 

2 : while_loop_set = set of while statements 

3: SLlCE(while_loop_set) 

//At this point, all the statements belonging to the slice are marked 
4: end function 
5: function SLlCE(stmt_set) 

6: for all stmt € stmt _ set do 

7: if is_not_marked(stmt) then 

8: mark(stmt) //Add stmt to the slice 

9: S lice (Definition_ Sites (stmt)) 

10 : end if 

ii: end for 

12 : end function 

13: function DEFINITION _ SITES (stmt) 

14: if stmt = x := expr[xl, . . . ,xn] then 

return HD stiri t(xl) U ... U RD s t m t(xn) U CoMPOUND(stmt) 

15: end if 

16 : if stmt = if cond[xl, . . . ,xn] then SI else S2 then 

return RD s t m t(xl) U ... U RD s t m t(xn) U CoMPOUND(stmt) 

17: end if 

18: if Stmt = for i from exprl [xl, . . . ,xn] to expr2 [yl, . . . ,yp] do S then 

return RD s t m t(xl) U ... U RD s t m t(yp) U CoMPOUND(stmt) 

19: end if 

20 : if stmt = while condtxl,...xn] do S then 

return RD s t m t(xl) U ... U RD s t m t(xn) U CoMPOUND(stmt) 

2 i: end if 

22 : end function 


Example (cont’d). Let us apply our slicing algorithm to the piece of code given figure 
[4j This code has been picked from the end of the motivating example. For the sake of the 
presentation, the while statement will be denoted by “while” and the if statement by “if”. 

• Do_Slice call Slice with while_loop_set = { while }. Initially, the slice is empty, no 
lines are marked. Lines 3 and 6 are marked, then Definition_Sites(while) is run 
and gives RD 3 (i) U RD^(n) U {if} = {i=l, i=i+l,if}. 

• Slice is then called on {i=l,i=d+l,if}. i=l is processed first. Line 2 is marked and 

Definition_Sites (i=l) is computed. i=l does not read variables, thus we get i?Z?2(0) U 

{if} = {if}. 

• Slice is then called on { if }. Lines 1 and 7 are marked. DEPiNiTiON_SiTEs(if) gives 
RDi(up) U 0 = 0. Indeed, up is not defined in this piece of code and if has no compound 
control structure. So, no additional recursive call is issued. 

• Going back on the recursive calls, Slice({ i=i+l }) is called. Line 5 is marked, then 

Definition _SiTES(i=i-fT) is computed and gives RD§(\) U {if} = {i=l, i=i+l, if}. 

• Slice is then called on {i=l,i=i+l,if}. All these statements were already processed, so no 
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further recursive exploration is done. 

• Do_ Slice ends up with the slice defined by the marked lines {1,2, 3 , 5 ,6, 7 }. This slice 
excludes a[i]=a[i+n] which, indeed, does not influence the termination of the while loop. 


4.2 Step 2. Scalable Termination 

This section presents a scalable termination procedure, which scatters the termination proof 
into several proof obligations, on small programs with a single conditional loop. These proof 
obligations will be small enough to be handled successfully with the termination method WTC, 
presented in (2]. 

Here, although WTC is a tool that can handle programs (with nested loops), we can see 
WTC as a termination engine that takes as input a single loop and an execution context , and 
tries to prove that this loops terminates under the given context. WTC can either answer OK, 
which means that the program actually terminates, or DK, which is inconclusive. 


Basically, our algorithm is based on the structure of the program to analyse. As expressions 
have no side-effects, they terminate. Breaks and asserts terminate. A sequence of instructions 
terminates if each terminates (given their execution context). For tests, we have to prove the 
termination of each branch under their respective contexts. A for loop terminates if its body 
terminates (in our simple version of for loops). A (single) while loop terminates if we are able 
to exhibit a ranking function. This is done by a call to our tool WTC. To handle nested loops, we 
can replace the inner loop by a summary (3.21 of its behaviour, and call WTC on the outer loop 
with a lesser body. 


Algorithm The previous remarks are implemented in Algorithm [2] The main function Mod- 
ularTerm takes as input a statement and a structure that is able to give an over approximation 
of the context of each statement of the program under analysis. These invariants are computed 
using linear relation analysis [7], implemented in the Aspic tool (0). ModularTerm proceeds 
the abstract syntactic tree with a depth-first traversal, evaluating each sub-tree to the value OK 
if it terminates, or DK if the analysis does not succeed to answer. If a sub-tree is evaluated to DK, 
the analysis fails and stops with DK output. 

Let us focus on while loops. To analyse loops, the algorithm : 

1. First tries to prove the loop body to terminate. If the loop body cannot be proved to 
terminate, then the analysis fails without having to analyse the loop itself. 

2. If the analysis succeeds, the termination of the loop is checked by applying the WTC 
method described in [2] on the loop itself, under its context. 

3. Then the loop is replaced by its summary (section [3.2| .The analysis continues with this last 
code. Notice that the subsequent calls to WTC will have to deal with simpler programs 
with a single loop, which reduces scalability issues. 

Notice that linear relation analysis expresses the invariants by a convex polyhedron, which 
over-approximate the actual possible values of the variables. As a consequence, the precondition 
of the loop needed to apply WTC (stored in pcinvs), as well as the summary of the loop are 
over-approximated. These approximations can make unprovable programs which could be proved 
successfully with WTC, on the cases where the ILP can be processed with a reasonable amount 
of resource (time and memory) (see Section |fi}. 

Example (cont’d). Our termination procedure processes the loops 0, 1, 2, 5, 4 and 3 in 
this order (deep-first search). For the sake of the presentation, we will restrict the discussion to 
the first steps of the algorithm. 
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Algorithm 2 Scalable Algorithm for proving termination 


i: function MoDULARTERM(statement,pcinvs) 

2: if statement = x:=expr then return OK 

3: end if 

4: if statement = stl;st2 then 

5 : res <— ModularTerm(stl, pcinvs) 

6 : if res = OK then 

7 : return ModularTerm(st2,pcinvs) 

8: else 

9 : return DK 

10: end if 

ii: end if 

12: if statement = if cond then SI else S2 then 

13: res l— ModularTerm(stl, pcinvs) 

14: if res = OK then 

15: res' 4— ModularTerm(st2, pcinvs) 

16: return res' 

17: else 

18: return DK 

19: end if 

20: end if 

21: if statement = for i from expl to exp2 do S then 

22: return ModularTerm(S, pcinvs) 

23: end if 

24: if statement = while cond do S then 

25: res 4— ModularTerm(S, pcinvs) 

26: if res = DK then 

27: return DK 

28: else 

29: context i— getContext(statement, pcinvs) 

30: res l— WTC(context, statement) 

31: if res = DK then 

32: return DK 

33: else 

34: Compute a summary of the loop and replace in the code. 

35: return OK 

36: end if 

37: end if 

38: end if 

39: end function 

After instrumenting the code with loops labels and calling C2 fsm and Aspic on the resulting 
code, we find the following execution contexts for the loops : 

• loopO : {r > 0,p > q,p > r,p > 1, m > 0, i + m + q + r > j + 1} 

• loop5 : {i + m + q > j + 1, m > 0,p > lq < 0, r = 0} 

WTC succeeds to prove the termination of loopO under its context (its finds the ranking 
function q + r), and also gives the following approximation for its behaviour : {j < jo A i > 
io A h = ho A n = no A i + q = io + qo A j + ro = r + jo} whose summary is : 

iO = i; jO = j; qO = q; rO = r; hO = h; nO = n; 
if(!(<=j0 && i>= iO && h=h0 && n=n0 && i+q=i0+q0 && j+r0=r+j0)) 
break; 

Loopl and loop2 are processed in the same way. At the end, the outer loop loop5 no longer 
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contains while loops, which were all substituted by an abstraction of their effect on the variables. 

The termination of loop5 comes from the two first conditions at the beginning of loop5, 
whose global effect would be equivalent to the assignment m = m - 2*min(p,m). As p > 1 , 
m strictly decreases at each step of the loop and will end up with the value 0, ensuring the 
termination. A call to WTC ends with m as ranking function and gives a summary for loop5. 

In the same way, the process continues with the remaining loop4 and loop3, and ends up with 
the final answer OK, meaning that the program always terminates. 

5 Extensions 

5.1 Interprocedural analysis 

We add the notion of function calls and a main. Dealing with local variables, parameters, and 
function calls is rather classical. The main restrictions are that we avoid recursive functions and 
modifications of the parameters and global variables during the function calls. 

(function}::= (declaration list) (statement list) 

(funcall)::= (var) := (functionname) ( (varl) ... (varn) ) 

To handle functions, we first compute invariants for all program functions f: pcinvsf. Then, 
if the current statement is a function call x:=f (xl, . . .xn): 

1. Compute the projection of the call context at the current control point ( pdnvs ca u er (progpoint )) 
on the union of variables x\ ... x n and the global variables. This invariant is called 
callcontext. 

2. Call recursively ModularTerm on the function body whose context is modified by the call 
context : pcinvs ca u ee (~l callcontext. 

5.2 Extensions to “full” C 

For the moment, our tool is restricted to a subset of C and could not handle a general C program. 
However, it is always possible to extend the set of analysable programs with an appropriate set 
of normalizations, implemented as a preprocessing. We give thereafter two important normal¬ 
izations which should enlarge drastically the class of analyzable programs. 

For loops We assume the for loops to be Pascal-compliant: for i from exprl to expr2 
do BLOCK(i);. In C, the for loops can be much more general and used, for exam¬ 
ple, to iterate on linear data structures: for (ptr=first ; ptr != NULL; ptr=next(ptr)) 
BLOCK (ptr). It is easy to design a preprocessing which detects non-Pascal-compliant for 
loops, and turn them into a while loop: ptr=first ; while (ptr ! =NULL) { BLOCK(ptr); 
ptr=next(ptr); } 

Pointers We assume the program to be pointer-free. In C, the use of pointers complicate 
the data-dependence analysis, hence the slicing (because of reaching definitions) and the 
invariant analysis. On the following program: p = &a; q = &a; *p=l; *q=2; x = a; 
The reaching definition of a in x=a should be RDx=&{a) = *q=2. Also, the invariant of 
x=a should implies x = 2. To make these analysis possible, the interferences must be 
analyzed carefully, thanks to pointer analysis |3]- However, the data-dependences are over¬ 
approximated, thus this will affect the size of slices. As for the invariant computation, the 
obtained data-dependencies should be analyzed carefully to produce an integer interpreted 
automaton leading to correct invariants. This analysis is not trivial and is left for future 
work. 
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Benchmark 

#Progs 

LoCB 

LoCA 

Regressions 

WTC(s) 

SToP(s) 

WTC1 

50 

28 

21 

3 

0.92 

2.45 

WTC2* 

6 

55 

39 

0 

3.66 

3.52 


Table 1: WTC1 and WTC2 denote middle-sized benchmarks taken from our previous experi¬ 
ments in [2]. WTC2 consist on a bench of 8 sorting functions from the literature, and WTC1 are 
also classical codes including sipmamergesort,our motivating example. For each benchmark, we 
give its number of programs, the average number of lines of codes before(LoCA) and after (LoCB) 
slicing, Regressions denote the number of regressions (examples that were proven OK with WTC 
and for which SToP now answers DK). We also give average execution times of each method. 


6 Experimental results 

We implemented our method as a driver over WTC, written in C++. The total number of LOC 
is 3000 for the driver itself, and 150 additional lines for statistics. The code intensively uses 
the source-to-source compiler infrastructure Rose ([[12]) : functions for parsing, constructing flow 
graphs, searching in the code structure, pretty printing and instrumenting C codes. 

Table[l]give an extract of the experiments we made with our tool SToP (the entire benchmark 
is available on http://compsys-tools.ens-lyon.fr/stop 

The experiments were done on a Dual Core 2Ghz. As we expected, the execution times on 
middle-sized examples are much larger with SToP than WTC, mainly because of the cost of slicing 
and producing intermediate files. In future versions of SToP , we will investigate the opportunity 
of calling WTC on larger subprograms (some nested loops can be handled with a unique call to 
WTC). For sorting functions, the method shows it pertinence in terms of timing results and in 
terms of precision (it handles sipmamergesort in 22 seconds, but we had to manage the very 
last step by hand by providing a coarser abstraction for loop5). Thus SToP is able to deal with 
larger programs than WTC and seems to scale well. More experiments remains nevertheless to 
be done. 


7 Related works 

As far as we know, this is the first tentative of proving termination of C programs in a modular 
way. Previous papers prove terminations of kernels, and other papers such as [3] use what they 
call “C abstractors” to make benchmarks but no general algorithm is given. Our algorithm is a 
driver built upon WTC, a previous toolchain to prove the termination of (little) C codes. To 
improve its precision, we could use (instead of WTC) other methods and tools to prove fragments 
of code : 

• The methods described in previous papers on termination such as e, in or more spe¬ 
cialised methods for other kinds of programs such as lists or trees ([10]). In these last cases, 
the numerical invariants that we precompute may not be precise enough, though. 

• Instead of testing if a given code fragment terminates under a given over-approximation 
of its context, we can use the method described in [6] to compute (sufficient) termination 
preconditions, and check if these preconditions are satisfied under the given context. 

As proving termination is undecidable, all these methods may positive results when other ones 
timeout or give DK answer, thus they could be used as “on-demand” back-ends. 
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8 Conclusion and Future works 

In this paper we have presented a framework for proving the termination of C programs in a 
modular way. We used WTC as a tool for proving termination of simple loops, but the method 
is fully adaptable to other termination engines. The preliminary experimental results show that 
they are relatively few regression cases comparing to the previous work published in [2], and we 
are able to deal with larger programs such as sipmamergesort in reasonable time. 

Future work include more tests to improve the reliability of our tool suite with respect to 
C variants, and on much bigger programs such as linux drivers and image processing codes. 
In particular, the size of the sub-programs generated by SToP expresses a trade-off execution 
time/precision which needs to be investiguated. 


References 

[1] A. Aho, R. Sethi, and J. Ullrnan. Compilers: Principles, Techniques, and Tools. Addison- 
Wesley, 1986-2006. 

[2] C. Alias, A. Darte, P. Feautrier, and L. Gonnord. Multi-dimensional Rankings, Program 
Termination, and Complexity Bounds of Flowchart Programs. In 17th International Static 
Analysis Symposium, SAS'10 , Perpignan, France, September 2010. 

[3] W. Amme and E. Zehendner. Data dependence analysis in programs with pointers. Parallel 
Computing , 24(3-4) :505-525, May 1998. 

[4] Aaron R. Bradley, Zohar Manna, and Henny B. Sipma. Linear ranking with reachability. 
In 17th International Conference on Computer Aided Verification (CAV), volume 3576 of 
Lecture Notes in Computer Science , pages 491-504. Springer Verlag, July 2005. 

[5] Michael A. Colon and Henny B. Sipma. Practical methods for proving program termination. 
In lfth International Conference on Computer Aided Verification (CAV), volume 2404 of 
Lecture Notes in Computer Science , pages 442-454. Springer Verlag, January 2002. 

[6] Byron Cook, Sumit Gulwani, Tal Lev-Ami, Andrey Rybalchenko, and Mooly Sagiv. Proving 
conditional termination. In Proceedings of the 20th international conference on Computer 
Aided Verification, CAV ’08, pages 328-340, Berlin, Heidelberg, 2008. Springer-Verlag. 

[7] P. Cousot and N. Halbwachs. Automatic discovery of linear restraints among variables of 
a program. In 5th ACM Symposium on Principles of Programming Languages (POPL'78), 
Tucson, 1978. 

[8] P. Feautrier and L. Gonnord. Accelerated Invariant Generation for C Programs with Aspic 
and C2fsm. In Workshop on Tools for Automatic Program Analysis, TAPAS'10, Perpignan, 
France, September 2010. 

[9] Robert W. Floyd. Assigning meaning to programs. In Symposium on Applied Mathematics, 
volume 19, pages 19-32. A.M.S., 1967. 

[10] Peter Habermehl, Radu Iosif, Adam Rogalewicz, and Tomas Vojnar. Proving termination 
of tree manipulating programs. In Automated Technology for Verification and Analysis, 
volume 4762 of Lecture Notes in Computer Science, pages 145-161. Springer-Verlag, 2007. 


RR n° 8166 



14 


Andrieu & Alias & Gonnord 


[11] Andreas Podelski and Andrey Rybalchenko. A complete method for the synthesis of lin¬ 
ear ranking functions. In Verification, Model Checking, and Abstract Interpretation (VM- 
CAF03), volume 2937 of Lecture Notes in Computer Science , pages 239-251. Springer Ver- 
lag, 2004. 

[12] D. J. Quinlan. Rose: Compiler support for object-oriented frameworks. Parallel Proc. 
Letters, 2000. 

[13] F. Tip. A survey of program slicing techniques. Journal of Programming Languages , 1995. 


Inria 





RESEARCH CENTRE 
GRENOBLE - RHONE-ALPES 

Inoval lee 

655 avenue de I’Europe Montbonnot 
38334 Saint Ismier Cedex 


Publisher 

Inria 

Domaine de Voluceau - Rocquencourt 
BP 105 - 78153 Le Chesnay Cedex 
inria.fr 

ISSN 0249-6399 




